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Process Component ATP Requests [LFM] 

Component ATP requests 32 from fulfillment server 16 are received at each of 
the appropriate LFMs 22. As discussed above, a LFM 22 is generally responsible for 
managing component ATP requests 32 and communicating between fulfillment server 
5 16 and associated ATP server 14 over the life of ATP request 30. In one embodiment, 
LFM 22 is involved in quotation, promise, acceptance, shipping, and archive 
operations for associated ATP server 14, If specified sourcing preferences exist, 
component ATP requests 32 may include this information, such that LFMs 22 may 
identify and process component ATP requests 32 accordingly. If there are no 

10 specified sourcing preferences, LFMs 22 may be capable of identifying relevant 
component ATP requests 32 based on the user, customer, or product. At a particular 
ATP server location, LFM 22 receives component ATP request 32 and generates a 
quotation request to ATP server 14 using the command syntax suitable for the 
particular associated planning engine. As part of this processing, LFM 22 evaluates 

15 the business constraints encapsulated in component ATP request 32 and acts 
accordingly. 

Planning engines may vary relative to the requirements of this interface. As 
an example, FP engines typically do not maintain ATP fi-om which request 
transactions will consume allocated product availability. Each component request is 

20 planned against a representation of finished goods inventory, available materials or 
capacity, and other suitable factors to determine product availability. There may be 
little functionality for controlling the output structure of the resulting quotation 
response from the standpoint of shipment timing and lot sizing. In this situation, LFM 
22 may submit the quotation request as a planning transaction and evaluate the 

25 quotation response according to the business constraints encapsulated in component 
ATP request 32. If the response from ATP server 14 does not meet these 
requirements, LFM 22 identifies this and sends a failure notification to fulfillment 
server 16. 

For example, if the ship complete attribute within component ATP request 32 
30 requires the request to be met in full, and the availability in ATP server 14 was less 
than the requested quantity attribute, then LFM 22 might indicate the component 
quotation 34 as having failed and provide an appropriate descriptive failure 
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annotation. This front-line evaluation may be important since, depending on the 
planning engine, the ATP server response may be multi-dimensional (offering 
multiple options). Providing response evaluation at the LFM level rather than at the 
fulfillment server level allows failure conditions to be identified and summarized 
5 before component quotations 34 are sent back to fulfillment server 16, thereby 
reducing overall network load. 

As an example of a multi-dimensional ATP server response, consider a given 
request line item (e.g., 100 wheels on May 8), for which the response might be that 60 
wheels are available on May 8 for $22, and/or 30 wheels on May 10 for $16, and/or 
10 100 wheels on May 12 for $16. These are multiple options for the line-item quote. 
System 10 may allow for the incorporation of rules and ranges. For example, the 
ability to take 30 wheels on May 10 and the remaining 70 wheels on May 12 may be 
constrained if the option for $16 on May 12 includes a quantity restriction 
inconsistent with this. 

15 As a fiirther example, consider a three line-item request (e.g., 100 wheels, 25 

simple axles, and 25 complex axles dehvered proportionally on May 8). Individual 
line-item quotes can be computed as above, with multiple options, then combined in 
some suitable manner. For example, the simple axles might be available on May 9, 
15 uinits, and May 11, 25 units, for $10. The complex axles might be available on 

20 May 8, 10 units, and May 10, 25 units, for $25. Ignoring the proportionality business 
constraint included in the request, delivery of products satisfying the order might 
occur over several days. May 8 through May 12, as appropriate, A proportionality 
business constraint, however, might mandate that line-items only be delivered in 
amounts proportional to how they were requested, since for example it may do no 

25 good to be delivered wheels if no axles are delivered. The above might result in the 
following example multi-dimensional quote that includes multiple line-item quotes 
and obeys an example proportionality business constraint: 



May 9 ~ 40 wheels, 10 of each axle, for $(22*40 + 10*10 + 25*10) 
30 May 10 - 28 wheels, 7 of each axle, for $(16*28 + 10*7 + 25*7) 

May 10 - 60 wheels, 15 of each axle, for $(16*30 + 22*30 + 10*15 + 25*15) 
May 1 1 - 88 wheels, 22 of each axle, for $(16*30 + 22*58 + 10*22 + 25*22) 
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May 12 - 100 wheels, 25 of each axle, for $(16*100 + 10*25 + 25*25) 

In one embodiment, system 10 supports many different business constraints, 
some of which may need one or more extra fields to be specified. To model this, the 
5 business constraint field could be an extension selector, as described in U.S. Patent 
Nos. 5,764,543 and 5,930,156, both of which are incorporated by reference herein. 
Additional extension fields might become operative when a corresponding extension 
value is inserted into the extension selector field. For example only and not by way of 
limitation, a maximum variance constraint might be specified on ATP request 30 and 

10 an additional field added to the request model called max_yariance _percentage that 
allows the client 12 or an associated user to specify the amount of variance from a 
requested quantity that will be tolerated. That field may not exist and may not take up 
any memory space when the maximum variance constraint is not specified. System 
10 may allow such an extensible model or capability to be used with respect to any or 

15 all business constraints described herein, providing significant flexibility and an 
important techrdcal advantage over flat or other previous modeling techniques. 

Within system 10, various LFMs 22 may compute a variety of partial 
quotations or partial promises, for example, containing no detail of supply 
availability. When this occurs, fiilfiUment server 16 may be tasked with creating a 

20 combined promise using the partial quote information. Worse, since the LFMs 22 
may be backed by inferior ATP servers 14 incapable of providing suitably rich ATP 
information, fiilfillment server 16 may need to deal with a varied sophistication of 
component quotations or component promises and still form the best possible 
quotations or promises for ATP request 30 as a whole. Performing this task properly 

25 may require any number of business constraints to drive the interpretation of the 
various component quotations or component promises, or to mutate the various 
component quotations or component promises as appropriate. Extensibility within the 
models representing LFMs 22 allows different constraints for mutating component 
quotations or component promises to be modeled. The present invention 

30 contemplates extensibility with respect to any suitable business constraints described 
herein. 



